Horses and Barn Doors: Evolution of Corporate Guidelines for Internet Usage

Intel’s Internet usage policy evolved from practically non-existant to explicitly defined – all in reaction to changing conditions and security threats. This paper covers the evolution of Intel Internet access policy, a continual struggle to close the barn doors before the horses get out. Throughout the paper, we outline key lessons we have learned during the policy-making process. It discusses Intel’s first taste of the Internet, Intel’s policy-making process, the open access policy of that period, and the resulting security challenges. It then covers the imposition of a stricter policy and implementing a firewall to enforce that policy. The paper proceeds to describe today’s problems, the majority of which center around Intel people accessing the Internet. In response to this problem and growing numbers of people wanting to use the Internet, Intel has drawn up explicit corporate guidelines on Internet use. These guidelines are then compared to various Acceptable Use Policies and Netiquette guides. The paper concludes with some additional tasks Intel is planning in order to keep the barn doors closed. Intel’s Introduction to the Internet Intel Corporation has had access to the Internet since 1987. At that time, we had a dial-up connection to the now defunct CSNET. We dialed Boston from Santa Clara, California several times a day to pick up and drop off mail. We did not have any kind of Internet access policy. We felt secure in having complete copies of all messages sent in and out and having our modems block dial-ins. While the dial-up connection provided muchneeded mail access to and from customers, vendors, and research partners, functionality was too limited. Delivery was so slow at times (days!) that paper proved a quicker and more reliable communication medium. Users complained that carrier pigeons would deliver mail faster. The long distance calls grew to be expensive. Because of these concerns and the desire for direct FTP and telnet access to the Internet, in 1989 we traded our CSNET dial-up connection for one with direct IP access over a leased line. An increase in functionality always means an increase in risk, as we will see in the next section. The Challenges of an Open Door Our first policy was this: anyone in the company could go out on the Internet, and rlogin, telnet and FTP access into Intel would be blocked. WE were the access providers, and so we imposed this policy unilaterally. The only place this was written down was in the router access list configuration. What were the results of our (wide) open door? We received many complaints about Internet access from various system administrators around the company. They did not like the gaping door. Later, with unsolicited help from federal agents, we found some crackers who did. Key Lesson #1 – Research Policy Issues Key Lesson #2 – Consult with users and stakeholders on policy decisions Key Lesson #3 – Make the policy available and readable. Our policy was incredibly naive. We did not think it through in depth and did not realize how easy it would be for intruders to exploit gaping holes. Furthermore, we did not have buy-in to our policy. System administrators weren’t comfortable with it. Even worse, they were uncomfortable with a policy they couldn’t even read. Things had to change. Shutting the Door Part Way The problems we encountered forced us to realize our mistakes. We looked into Internet access schemes implemented at other companies. We wrote down and proposed a limited access policy. This document was circulated for comment by electronic mail and presented at various user forums within Intel. Finally, we had the policy approved by an internal change control group. This was an official stamp that gave us legitimacy. Our new policy restricted outbound Internet access to specific systems. Inbound access was limited to certain protocols going to dedicated servers. The outbound systems, controlled by site administrators, would be tightly controlled. Applications for Internet access systems would have to be signed by site network managers, the system administrator’s manager, and our internal Information Security group. Applicants promised to read and obey our policy, which was circulated with the application forms. 1993 LISA – November 1-5, 1993 – Monterey, CA 9 Horses and Barn Doors: Evolution of Corporate Guidelines Hambridge & Sedayao Key Lesson #4 – Get key people to buy into a policy. Better yet, get some kind of official stamp of approval. Key Lesson #5 – Forms with signature loops are a way of making sure that people are serious about wanting something. It is also a way to inform key parties of change and get their buy-in. We managed to get people involved in making our policy. They bought into it, and we got an official stamp of approval from a internal group. By using forms, we weeded out people who weren’t serious about managing Internet access systems. Moreover, we gave our Information Security group a chance to review and buy into the decision of who would want access. Key Lesson #6 – Provide metrics on usage and quality of service. We made the decision that we would track how much the gateway was used and who was using it. We look at sheer volume, such as how many bytes each access system exchanges with the Internet and how many messages are exchanged through the gateway mail servers. We also decided to track some service metrics like mail delay through the gateway. An Internet gateway status and usage report is produced and widely distributed every quarter. Keeping metrics has proven to be a good decision. We can track utilization, which helps us with capacity planning and with justifying new equipment. Management, initially unsure about funding our gateway, is usually persuaded when they see how much their people are using the Internet. Finally, keeping metrics gives us some idea how well we are managing the gateway. Ironically, by shutting the door part way, usage boomed. Throughout the six years we have had mail capability, we have witnessed an exponential growth in the amount of mail coming into and going out of the company. This growth is consistent with Internet growth trends industry wide. (See Figures 1 and 2.)[1] Since Intel is a multi-site, multinational operation, almost all Intel sites dedicated a number of machines to provide ftp and telnet capability for groups within the site. With growth in the number of Internet knowledgeable employees, (as well as those who have heard of the Internet but know little) we’ve seen demands for accounts on these machines skyrocket. We’ve also seen a corresponding growth in different kind of security problems – from Intel instead of to Intel. Most of these problems stem from people attempting logins to defunct accounts, or naively trying to telnet to ftp machines and vice versa. Still, even these innocent mistakes mean time and trouble. This is time and trouble for the system manager of the machine where the ‘‘break-in’’ is attempted as well as Intel’s Internet contact and the system administrator of the internal Intel machine from which the ‘‘attempt’’ occurred. Intel personnel must then check system logs to determine who was logged in at the time, then contact those people to find out whether intent was indeed malicious. All of this takes time from resources which function better as network and system managers than High School Vice Principals. We discovered that almost all of our policy focused on system and network administrators and not on users. Although we put conditions on how the access systems should be administered, we did not provide any tools or help to do so. We should not have been surprised that some of the Internet access systems were far more open than we liked. The incidents with misguided users sparked another fear. We could conceive scenarios [2] where a user could create an incident severe enough to cause Intel to shut down or tremendously restrict our Internet connection. Getting the Horses to Behave To combat these problems, an Internet Security Task Force was formed. This ad hoc group consists of representatives from Corporate Information Security and system managers and users. We had learned from past experience that only by getting people involved could we create workable policies. Corporate Information Security bears the responsibility of protecting Intel’s intellectual property assets. This group sets policy and procedures for Information Security, publishes a yearly summary of those policies, and has recently developed a class on information security for Intel employees. In its Internet Policies, the Task Force has tried to maintain a balance between getting people to information (and information to people) and maintaining reasonable security. First, although most of us eschew bureaucracy, we ask those users requesting accounts on machines which have Internet telnet and ftp access to justify having an account. We have found that many people think they need direct access to the Internet in order to send Internet mail. Since sending Internet mail is possible from any networked machine at Intel, we inform the user how to send mail and this eliminates the need for the account. We do ask that the user have a legitimate business reason for telnet and ftp access before we grant the account. Second, accounts on Internet accessible machines are set to expire at 6 months. If a user doesn’t use the account enough to notice it has expired, it will not be an open door. This is a minor inconvenience to users who need their accounts (especially compared to the benefits). Key Lesson #7 – User education is critical Key Lesson #8 – Create explicit and enforceable policies 1